I would remove the details, some of which are probably wrong.

Yea could do. It would be nice to show that we have some idea about the non trivial parts though.

I'm not convinced the overhead of the Python interpreter is larger in the browser, unless you can link to an independent study.

That's generally cited in the pyodide community. The standard numbers are <2.5x native for compiled stuff (based on a 2019 paper), 2-5x for python (cited on pyodide issues in their roadmap and more based on their benchmarks). If you actually look at the pyodide benchmarks you could say 2 -10x though. I'll put a reference in. I don't think they have rigorously isolated the effect of the interpreter.

Pyodide is not independent of course in that sense.

Ok, perhaps link to a recent evaluation by PyOdide, then?
(I would stress recent, though; I wouldn't trust 2019 numbers to still apply currently, given that we're talking about a fast-moving ecosystem)

On performance numbers: I did a pretty long search and didn't find papers newer than the 2019 one. That paper "Not so Fast" is already an evolution to the older WASM paper which showed close to native performance for a different benchmark set. I recommend reading both. But the lack of newer studies is why new published benchmarks (even just as blog posts) for us, and for specific domains, are so important. The numbers I recently shared internally are all over the place, sometimes WASM is even a bit faster, often a bit (<2x) and sometimes much slower for compiled (10x+). But much is in the 2-5x range as the often cited numbers. My own numbers aren't able to isolate the interpreter overhead.

Pyodide has more numbers, but unfortunately they don't run their CI benchmarks regularly anymore it seems. You need to run them locally or find snapshots in issues. And even with those numbers available, to me the python browser overhead is anecdotal because I am unsure those benchmarks isolate the interpreter well (not because they are bad but because I didn't understand myself whether they do. And again, maybe I didn't find the right sources and others have a better understanding).

Isn't "shipping pre-compiled native extensions" exactly what we do in emscripten-forge? Why would it be more impractical for the browser than for native code?

The key word is everything here. We can't ship compiled extensions for every loop and small code snippet. That is what is impractical on native and in the browser. Maybe it can be written better.

But this doesn't make sense either. The equation is for same for Wasm than it is for native code. Performance-critical Python scientific code is never written in pure Python. It's already available either in C/Rust/C++, or as Numba/Cython.

2-5x slower for pure Python code sounds severe, but it's also small compared to the 50-100x faster that you can get with C/C++/Rust vs. pure Python. So you would want native extensions in the same situations regardless of whether the Python interpreter is running in Wasm or not.

I guess that depends on the situation and absolute numbers as well, 2x can be decisive or not at all.

Underlying is the argument that you have more incentives to JIT compile Python in the browser:

• you generally pay a larger performance hit for Python in the browser than for compiled stuff (2x+ based on the numbers we cited).
• it's more complicated to compile and load extensions manually in the browser. It's probably possible since done on the pyodide side afaik but seems involved in any case for the user.
• you are in dynamic, notebook style situations requiring quick solutions that you can trigger immediately from the same interface.
• What else would you do for acceleration? Multi threading, GPU aren't easily available.

And then you have libraries that use Numba anyway for acceleration and that might work out of the box if we had it available.

I'm not even sure I still have commit rights on Numba, and we have nobody else in the Numba team. So this sentence is a lie AFAICT.

Ok, core developer is not correct? Or the upstream relationship?

I have not contributed to Numba since 2017 or 2018, I think. I don't have any reliable evaluation of my upstream relationship, but I wouldn't count on it. By default you cannot assume that we are in a privileged position.

I do have expertise in Numba, though, and the internals don't seem to have changed much. So you could stress that we have in-house Numba expertise (and such expertise is rather rare).

Ok that sounds good to me. We can just write it as such.

I would say it's up to us to show a proof of concept before getting some funding. A sponsor will want dependable upstream changes for full-blown Numba functionality.

I thought about this as well. But my understanding is that the proof of concept itself is a significant undertaking, and probably the main challenge right now. Under that hypothesis, funding already for the PoC would be necessary because otherwise we may not be able to stem it ourselves.

I'm not sure the effort to demonstrate JIT-acceleration of NumPy array code is that significant. @anutosh491 could perhaps give more insight.

Let's remove the MCJIT tidbit?

Yes